Many computer systems are organized according to a client/server metaphor. In client/server computing, in general, end users are each provided with a desktop computer or terminal known as a "client." The clients are connected using a network to another computer known as a "server" because its general function is to serve or fulfill requests submitted by clients. Application programs running on the clients prepare requests and transmit them to the server over the network. The server immediately executes each request as it is received; this is often called "on-line" or "connected" execution of work.
However, in some environments, deferred or disconnected execution is preferred or required. For example, a particular application may require entry of data or execution of any operation at a later time after specific conditions are met. As another example, deferred execution can be applied to data processing used in product order entry and shipping by a manufacturing company. In the conventional approach, a single application program handles both order entry and order shipment. With deferred execution, an order-entry program receives orders, and then adds an entry into the queue for a shipping application. Since less work is done at order-entry time, the order-entry application runs faster. Such deferred execution is also termed "asynchronous processing." Known implementations of asynchronous processing in client/server computing environments are inefficient and not robust.
Queuing can be used to implement deferred execution of work. In a system with queuing, a request for work is entered into a queue of requests, and the system defers processing of the request until later, such as when the requesting process has completed the task, process or transaction that created the request. Queuing has been recognized as an important component of systems that mimic human business processes or work flow.
Processing each client/server request exactly once is often important to preserve the integrity or flow of a transaction. Once-only processing must occur even when a processor, system, or network fails. For example, if the request is an order for a number of shares of stock at a particular price, execution of the request zero or two times is unacceptable even if a network or system failure occurs during transmission, receipt, or execution of the request. Integrating transaction-processing technology with queuing technology to provide "persistent queuing" can fulfill the requirement of once-only processing.
Some known transaction processing monitor software ("TP monitors") includes persistent queuing functions. Persistent queuing is also supported in "message-oriented middleware" (MOM) products such as IBM's MQ Series. However, current implementations of persistent queuing suffer from notable drawbacks. For example, past persistent queuing systems lack means for manipulating or managing data contained in a message, which is the element stored in a queue. Such systems also have insufficient means for logging, recovering, and storing messages, and lack means for disaster recovery, querying or displaying executed queued messages; messages are discarded after execution.
Another disadvantage of MOM systems is lack of transactional integrity. Generally, completing a transaction requires updating both a database and a separate queue, a process known as two-phase commit. Maintaining consistency between the database and the queue requires special effort on the part of the application programmer. Also, an external transaction coordinator, such as a TP monitor, is required. This makes the environment more complex to manage.
Such systems often store queued messages in a proprietary database that is inaccessible to application programmers or end users. Management of such databases complicates system management and may require additional education of users or administrators.
Such systems often store message queues external to an application and external to a relational database system required by users of the queuing system; accordingly, distributed transactions are required for communication with queues, creating unnecessary system overhead.
In addition, prior systems do not permit multiple external processes or applications, known as message consumers, to remove a message from the message queue. This is a significant limitation because in many business processes, multiple applications need to receive the same message.